|
Release Date:
June 18, 2001
Severity:
High (Remote SYSTEM level code execution)
Systems Affected:
Microsoft Windows NT 4.0 Internet Information Services 4.0
Microsoft Windows 2000 Internet Information Services 5.0
Microsoft Windows XP beta Internet Information Services 6.0 beta
Description:
There exists a remote buffer overflow vulnerability in all versions
of Microsoft Internet Information Services (IIS) Web server software.
The vulnerability lies within the code that allows a Web server
to interact with Microsoft Indexing Service functionality. The vulnerable
Indexing Service ISAPI filter is installed by default on all versions
of IIS. The problem lies in the fact that the .ida (Indexing Service)
ISAPI filter does not perform proper "bounds checking"
on user inputted buffers and therefore is susceptible to a buffer
overflow attack.
Attackers that leverage the vulnerability can, from a remote location,
gain full SYSTEM level access to any server that is running a default
installation of Windows NT 4.0, Windows 2000, or Windows XP and
using Microsoft’s IIS Web server software. With system-level
access, an attacker can perform any desired action, including installing
and running programs, manipulating Web server databases, adding,
changing or deleting files and Web pages, and more.
The Discovery:
Riley Hassell was at it again one day working to further advance
eEye's CHAM (Common Hacking Attack Methods) technology so that Retina
could better search for unknown vulnerabilities in software and
so that SecureIIS could better protect from unknown IIS vulnerabilities.
After a few hours of running some custom CHAM auditing code one
of our Web servers in our lab eventually came to a halt as the IIS
Web server process had suddenly died.
We investigated the vulnerability further and found that the .ida
ISAPI filter was susceptible to a typical buffer overflow attack.
Example:
GET /NULL.ida?[buffer]=X HTTP/1.1
Host: werd
Where [buffer] is aprox. 240 bytes.
The Exploit, as taught by Ryan "Overflow Ninja" Permeh:
This buffer overflows in a wide character transformation operation.
It takes the ASCII (1 byte per char) input buffer and turns it into
a wide char/unicode string (2 bytes per char) byte string. For instance,
a string like AAAA gets transformed into \0A\0A\0A\0A. In this transformation,
buffer lengths are not checked and this can be used to cause EIP
to be overwritten.
This sounds like any normal overflow to date, however there are
a few sticking points in doing anything useful with this. First,
you transform 2 bytes into 4, 2 of which you have no control over.
This would be a bad situation, but not impossible to exploit. However,
the 2 bytes that you do not have control over happen to be nulls.
Basically, we need to take this 2 byte string and somehow get it
to point to our code. Traditionally, we use our overwritten EIP
to jump to a call esp, or jmp esp, jumping back to code we have
positioned on the stack to implement whatever it is our shellcode
would like to do. In this case, however, there is a problem.
GET /a.ida?[Ax240]=x HTTP/1.0
The above example overwrites EIP with 0x00410041. Again, traditionally,
we insert our shellcode in the same buffer we overflow, however
we run into the problem that then our code would also face the same
expansion that our EIP bytes face. This makes writing shellcode
a horrible pain. There are two methods of doing this:
1. custom shellcode: It might be possible to write shellcode that
works fine with NULL byes every other byte. It would probably have
to be very simple, but this could be possible.
2. encode: You could probably write a decoder that takes a string
of 0x0041 and rewrites it on the stack into actual single byte code.
This would have to be written completely in 0x00bb opcodes, most
likely a challenge in itself (similar to the above custom shellcode,
but only a decoder would need to be written).
This would, of course only be possible if we could find a point
in memory that we could reach using only 0x00aa00bb. This gives
us only about 65k spots in memory to look for jump bytes, a pretty
dismal situation.
Exploiting Wide Char Strings In Practice
We got lucky using this method. We were basically limited to a very
very small range of memory in which to find jump bytes. We thought
we were losing the battle until we realized that IIS/ISAPI uses
0x00aabbcc as its memory range for allocated heap. We developed
a spray technique in an attempt to push enough data into the heap
so that the bytes we require will be there when we need to jump
to them.
For instance, in Windows 2000 Service Pack 1, we noticed that we
had request bytes at around 0x0042deaa. Since the closest we could
get to this was 0x00430001 (by overflowing with C%01 at the end
of our overflow string. This offered us an intriguing possibility
-- perhaps we could push more stuff into a request, causing more
heap memory to be used, pushing our request closer to where we want
to be.
GET /a.ida?[Cx240]=x HTTP/1.1
Host: the.victim.com
eEye: [Cx10,000][shellcode]
Now, we overflow the EIP with 0x00430043. With our new much larger
request, 0x00430043 happens to be inside the large C buffer we setup.
This acts as a slide in our code, executing down to our shellcode.
The Warning
Now for the warning. With this technique of forceful heap violation,
everything is relative to what is there to begin with. We noticed
that in any situation, we found 4-5 different copies of our requests
in the 0x00aabbcc memory range. This means that perhaps 0x430043
is not the best spot in memory, however it is the one we chose in
our forthcoming sample exploit (the exploit we will provide only
executes file writing; we provided Microsoft with shell-binding
code but will not publicly release this code). The other potential
problem with this attack is that different systems may have different
heap usages. In our internal tests, we noticed that heap usage differed
depending on which ISAPI extensions were enabled at any time. Also,
requests that cause faults handled by exception handlers that do
not free their heaps may cause certain parts of the heap to become
unusable, causing those spots to not be reused. This is not a problem
for Windows 2000 because it is nice enough to restart itself (giving
us a nice clean heap to work with). Windows XP appears to act similarly,
however we did not focus our research with this beta OS. This is,
however, potentially a problem with NT 4, which will crash if exploited
incorrectly. Again, like all other IIS overflows, this attack is
not logged, causing only a fault in IIS and crashing it.
All of the technical talk aside, we do have working exploits for
Windows NT 4.0 and Windows 2000 systems.
Proof-Of-Concept Exploit
We will be posting a proof-of-concept (file writing) exploit to
our Web site within the next few days.
The Fallout
According to Netcraft (www.netcraft.com), there are roughly 5.9
Million Web servers running IIS; however, the true number of IIS
Web servers is much larger when you count internal network servers.
Any of these Web servers that have the default .ida ISAPI filter
installed are most likely vulnerable.
Note on Windows XP beta:
As stated earlier, all versions of Microsoft’s IIS Web server
software are vulnerable to this flaw. This includes Windows XP beta,
Microsoft’s next-generation Operating System and the version
of IIS that is included with it. Microsoft is taking the necessary
steps to patch Windows XP before the final version ships to customers.
Funny:
Some people might wonder why this advisory does not contain the
typical eEye humor like most of our other advisories. Basically,
the reason is that this is our 4th remote SYSTEM level IIS vulnerability
and well...we've run out of jokes.
eEye Note:
Those eEye customers who are using the latest version of SecureIIS
are already protected from this vulnerability. SecureIIS is able
to stop known and unknown IIS vulnerabilities by looking for classes
of attacks instead of specific attack signatures.
Also, Retina 4.02, The Network Security Scanner, will be posted
to our Web site shortly. It includes many new features and functionalities
and also remotely checks for this latest Microsoft IIS vulnerability.
Vendor Status:
Microsoft has released a patch for this vulnerability that can be
downloaded from: http://www.microsoft.com/technet/security/bulletin/MS01-033.asp
Also eEye Digital Security recommends removing the .ida ISAPI filter
from your Web server if it does not provide your Web server with
any _needed_ functionality.
Copyright (c) 1998-2001 eEye Digital Security
Permission is hereby granted for the redistribution of this alert
electronically. It is not to be edited in any way without express
consent of eEye. If you wish to reprint the whole or any part of
this alert in any other medium excluding electronic medium, please
e-mail alert@eEye.com for permission.
Disclaimer
The information within this paper may change without notice. Use
of this information constitutes acceptance for use in an AS IS condition.
There are NO warranties with regard to this information. In no event
shall the author be liable for any damages whatsoever arising out
of or in connection with the use or spread of this information.
Any use of this information is at the user's own risk.
|